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A New Multicast Scheme for SmaB Groups 
Rick Bcivie 
T. J. Watson Research Center 
Hawthorne* New York 

Abstract 

Multicast is a technology that allows as application program to send data to more than one 
destination. An application program that uses multicast sends a single copy erf its data and the 
network delivers the data to a set of destinations on the applications'* behalf. Multicast is 
Important since it enable$ new da&es of applications such as video distribution, audio and video 
conferencing, networked collaborative work environments, multiparty networked games etc. The 
Intemat community has done a significant amount of work on IP multicast Over the last decade 
[ I - 10] and as a result, there are a number of multicast applications that arc used today on the 
Mbone, the multicast-capable virtual network that 5s layered on top of (portions of) the Internet 
[10]. Today's multicast schemes are scaleable in the sense that they can support very large 
multicast groups. But there are problems when a network needs to support a very large number 
of distinct multicast groups, such as a large number of small audio & video conferences, for 
example. In this paper, we describe a new scheme for multicast that complements the existing 
schemes. Whereas the existing schemes can support a limited number of very large multicast 
groups, the new scheme can support a very large number of small multicast groups for 
conferencing or other applications. 

Introduction 

The 1990's have been a time of explosive growth for the Internet and the Internet is becoming an 
increasingly important communications medium. Along with max) and chat, the Internet is 
increasingly used for applications like IP telephony and conferencing applications. It seems clear 
that multicast, the ability :o send data to a group destinations, will be increasingly important for 
applications like IP telephony and conferencing as weO as for other applications such as video 
distribution, collaborative work environments, multiparty networked games etc. 

There seem to be two kinds of multicasts that are important: a broadcast-like multicast that sends 
data to a very large number of destinations and a "narrowcast" multicast that sends data to a fairly 
small group. An example of the first is the audio & video multicasting of a working group session 
from an IETF meeting to sites all around the world. An example of the second is a 
videoconference involving 3 or 4 parties. We believe, for reasons described below, that it makes 
sense to use different mechanisms for these two cases. As the recently chartered reUab^ multicast 
transport group said on their web site, 'it is believed that a "one size fits all* 1 protocol will be 
unable to meet the requirements of $11 applications" [11]. 

Today's Multicast Schemes 

Today's multicast schemes were designed to handle the case in which there is a limited number of 
potentially large multicast groups. These work well if one is trying to distribute broadcast-like 
channels all around the world but they have scaleability problems when there is a large number of 
groups. 
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In some of these schemes, the nodes in the network build a multicast distribution tree for each 
<souree r multicast group> pair and they disseminate this multicast routing infbmuttion to places 
where it isn't necessarily weded - which leads to scaling problem* if there are a large number of 
multicast groups. 

Some other schemes try to limit the amount of multicast routing information that needs to be 
dissebinated, processed and stored throughout the network. These schemes use a "shared 
distribution tree" that is shared by afl the members of a multicast group and they try to Hmit the 
distribution of multicast routing information to just those nodes that "really need it", But these 
schemes also have proWeiris. Because of the shared tree, they use less than optimal paths in 
routing packets to their destinations and they tend to concentrate traffic in small portions of a 
network. They also require that all of the routers in a multicast tree "signal", process and store 
multicast routing information. And they require that multicast routing information for the various 
multicast groups be communicated across inter-AS administrative boundaries. These 
requirements cause scaleatifity problems and increase administrative complexity if there are a 
large number of multicast groups. 

Small Group Multicast ~ Introduction 

The multicast scheme proposed hem attempts to eliminate these problems for the case of small 
groups, It's very scateabk in that it can handle a very large number of these groups since the 
nodes in the network do »>t need to disseminate or store any multicast routing information for 
these groups. And since it doesn't use any multicast routing protocol, there are no inter-AS 
multicast routing "peering 1 ' issues to contend with. The proposed scheme has the additional 
benefit that packets always, take the "right" path as determined by the ordinary unicast route 
protocols. Unlike the "shared tree" schemes, the new scheme minimizes network latency and 
maximizes network efficiency, fa our view, this scheme removes some important obstacles that 
have, to this point, prevented the widespread acceptance and adoption of multicast and we believe 
this scheme can make multicast practical for vety large numbers of small groups — which as 
suggested above is a very important case. (The scheme described here is not appropriate for 
"broadcast" channels, e.g. broadcasting an IETF meeting all across the Internet - but solutions 
already exist for that problem. > 

The scheme proposed here takes advantage of one of the fundamental tenets of the Internet 
"philosophy", namely that one should move complexity to the edges of the network and keep the 
middle of the network sinrale. This is the principle that guided the design of IP and TCP and it's 
the principle that has mado the incredible growth of the Internet possible, The mason that the 
Internet his been able to scale so well is that the routers in the core of the network deal with large 
CIDR blocks as opposed to individual hosts or individual "connections". The routers in the core 
don't need to keep track of the individual TCP connections that are passing through them. And 
the IETF's diflserv effort is based on the idea that the routers shouldn't have to keep track of a 
large number of individual RSVP flows that might be passing through them. It's our belief that 
the routers in the core shouldn't have to keep trade of a large number of individual multicast 
flows either. 

Small Group Multicast - Details 

A New Multicast Scheme for Small Groups 3 
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The idea here is to let the ;$ource node keep track of the destinations that it wants to send packets 
to and eliminate the need for the routers to store any state for the various multicast groups, For 
example, let's suppose that A is trying to get his packets distributed to B, C <ft D in the figure 
below. 

B 



Rg C 

/ 

/ 

R6 R7 

\ 

\ 

R9 D 

This can be accomplished as follows. A can send a new type of packet to its default router> Rl, 
that includes the list of destinations for the packet The new packet type, let's call it a "snail 
group multicast" packet, i 3 a level 3 packet -which is to say that it's at the same level as IP In the 
protocol stack. In feet it lias pretty much the same function as an IP packet, except for the fact 
that it is addressed to a lb: of destinations as opposed to a single destination. Ignoring some 
details, the packet that A sends to Rl might look like this: 

Level 2 header: < dest = level 2 address of Rl > 

< sre - level 2 address-of A > 

< protocol » small group multicast > (ie a new level 3 packet type) 

Level 3 header: <dcst-BCD> 
<src~A> 

followed by the payioad that A wants delivered to B, C and D. 

When Rl receives this packet it needs to properly process the multicast. The processing that a 
router does on receiving one of these "small group multicast^ packets is as follows: 

* Perform a route table lookup to determine the "next hop" for each of the destinations listed in 
the packet. 

« Partition the set of deiitinatiojis based on their next hops. 

* Replicate the packet so that there's one copy of the packet for each of the next hops found in 
the previous steps. 

• Modify the list of destinations m each of the copies so that the list in the copy for a given next 
hop includes just the destinations that ought to be routed through that next hop. 

♦ Send the modified copies of the packet on to the next hops. 



R4 

/ 
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\ 

\ 
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So, in the example above, Rl will send a single packet on toR2 with a destination list of < BCD 
> and R2 will send a single packet to R3 with the same destination list, 

When R3 receives the packet, it vrifl, by the algorithm above, send one copy of the packet to R4 
with a destination list of < B > and 1 copy of the packet to RS with a destination list of < C D >. 
R4 will then forward a single packet on to B. And R5 wifl forward the packet that it receives on 
to R6 which will pass it on to R7. When the packer reaches R7, R7 will send a packet on to RS> 
with a destination Ust of < C >, and a packet on to R9 with a destination list of < D >. (The 
packets sent to R& and R9 could he "small group multicast" packets with a single .address in the 
destination list- or they coufd be ordinary unicast packets addressed to C & D respectively 1 .) R8 
and R9 will then forward appropriate packets on to C and D respectively. 

Note that it's important that the packet that is sent to a given next hop only includes destinations 
for which that next hop is 'he next hop listed in the route table. If the list of destinations in the 
packet sent to R4» for example, also incfodedC and D, R4 would $end "extra packets* on to 
those nodes on a less than optimum path. This could waste a lot of bandwidth if one is 
multicasting a vidooconfersoce, say. And this could cause serious problems when route loops 
occur since a multicast packet could "spray" large numbers of packets in a number of different 
directions as it travels around a loop. Since the packet that is sent to a given next hop only 
includes the destinations that are supposed to be reached through that next hop, these problems 
are eliminated. 

Note that when routing topology changes, the routing for a multicast flow wiO automatically 
adapt to the new topology since the path a multicast packet takes to a given destination always 
follows the ordinary, unic&st routing for that destination. 

Interoperability with Today's Boaters 

One disadvantage of the proposed scheme is that all the routers between the source and the 
various destinations need *o he able to properly process the new multicast packets. But, the 
scheme can be modified sightly to workaround routers that don't understand the new scheme. In 
the modified scheme, the packet that A sends toRl in the example above would look like this: 

Level 2 header: < dest * level 2 address ofRl > 

< sic « level 2 address of A> 

< protocol - IP > 

Level 3 header < dest - Rl > 
<src = A> 

< protocol = small group multicast > (ie a new protocol type) 
Level "3.5" header: < dest - B C D > 

! One advantage of using *n ordinary unicast for the last hop is that this allows hosts with 
"standard" TCP/IP stacks to receive the new multicast transmissions in a way that doesn't require 
any modifications in the host TCP/IP stacks. (If a source sends packets to a multicast "exploder'', 
source nodes can also' use "standard" TCP/IP stacks,) 
A New Multicast Scheme for Small Groups 5 
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<src = A> 

followed by the payload that A warns delivered to B> C and D. 

Note that a router that doesn't understand this new protocol wfll, upon receiving this kind of 
packet, send an icmp message back to the source if the router adhered to RFC1812, 
"Requirements for IP Version 4 Routers" - as all routers should. Section 5.2.7. 1 of RFC1812 
says that a router should send an ICMP Destination Unreachable message with code of 2, 
signifying Protocol Unreachable, if the transport protocol designated in a datagram is not 
supported tn the transport layer of the final destination 

So a router that doesn't understand this new protocol should send an icmp "destination 
unreachable, protocol unreachable" message back to the source. (If the icmp message is lost for 
some reason, a subsequent "small group multicast packet will cause another icmp to be 
generated,) So the source will know when a router doesn't understand the new protocol. 
Furthermore, since the Icmp message will include the initial part of the original packet, the source 
wiB also know the destinations that are not reachable via "small group multicast", so the source 
can u$e unicast packets to reach those destinations. When routing topology changes* additional 
icmp "destination unreachable, protocol unreachable" messages may be generated and the source 
may use unicasts for additional destinations. The source can also periodically send a "small group 
multicast 1 ' for the destinations that are on its "unicast list" la the list of nodes that it is reaching via 
unicast. Destinations that become reachable via "small group multicast" (ie those do not appear 
in subsequent icmp "destination unreachable, protocol unreachable" messages) can then be 
removed from the unicast list 2 . 

Thus, the "small group multicast" scheme can perform some multicasting in an environment that 
includes legacy* routers that do not understand the new scheme. It won't work particularly well 
if there are many routers that don't understand the now scheme but this backwards compatibility 
may be important since it makes some of the benefits of multicast possible before all the routers in 
a network have been upgraded which can be very useful since it may take some time to upgrade 
all the routers in a large network. 

RdiaMe Multicast 

One additional advantage of the small group multicast scheme is that it can be easily adapted to 
provide a "reliable multicast". The multicast scheme that we've been discussing to this point 
provides for an "unreiiabk" multicast in which there is no provision for retransmitting packets that 
are lost due to network congestion or because they were garbled during transmission due to 
Ene*noise, say. This land of u unreliable >r transmission is useful in many applications in which the 
"timeliness" of packet delivery is more important than getting an "old" packet that was lost 
re-transmitted. IP telepheny and video conferencing are applications in which the timeliness of 
packet delivery is importaat and the retransmission of lost packets is not use&l. 



2 Another possibility is to send a multicast "ping" periodically to the set of destinations and then 
use unicast to reach those destinations that don't respond to the ping. 
A New Multicast Scheme for Small Groups 6 
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In other applications, it makes sense to re-transmit a lost packet even if the retransmitted packet 
is going to be I or 2 hundred ntsecs late**. For example^ in a conferencing application, a reliable 
multicast could be used to reliably and efficiently transmit a foil presentation or the contents of a 
whiteboard or a shared document to multiple conference participants. 

A reliable multicast scheme can be built by extending the multicast scheme that we've been 
(focussing. The scheme would work as fbHowfc 

• An additional header which would include a sequence number and a checksum, similar to 
TCP, would be used tc keep track of the bytes that have been sent and the bytes thai have 
been successMy received by each of the receivers. 

• Each of the receivers would send acknowledgments or ACKs to inform the sender of the bytes 
that have been successfiiUy received. The checksum would be used to determine if a packet 
has been received error-free. As in TCP. the ACK includes a sequence number to indicate the 
last byte that has been successfully received (The sequence number could be that of the last 
byte 'successfully received or the first byte that has not yet been successfully received) 

• As in TCP, the sender concludes that a receiver has not successfully received a packet when it 
doesn't receive an appropriate ACK within a certain period of time. As in TCP, the sender 
re-transmits a packet fiat has not been successfully received. But unlike TCP, which 
re-transmits a packet to a single receiver, the reliable multicast scheme may need to 
re-transmit a packet tc more than one receiver, 

• When the sender need;? to re-transmit a packet, it uses a multicast for the re-transmission. 
Since the sender knows the receivers that it needs to re-send to, it can m-send tojuat those 
receivers. Thus the ^-transmissions are optimized and bandwidth is not wasted 
re-transmitting information to nodes that have already successfully received that information 
(If the sender needs to retransmit a packet to a single receiver, the "multicast" will, of course, 
be to a "tree" with a single leaf) 

Summary 

In summary, the disadvantages of the "small group multicast'* scheme are: 

• the extra bytes that are sent in a multicast packet for the list of destinations 

■ the need to use unicast packets in some cases to reach destinations that are behind "legacy" 
routers 

• the need for a new IP stack in sending hosts and routers 

• the fact that the scheme is not suitable for huge "broadcast-like" raulticasts. Ifs targeted for 
"small" conferences. 

The key advantages are: 

• h*6 very scaleable. It can handle a very large number of small groups. 

• the work involved is limited to just the nodes that are on the multicast tree 

• no per flow state information is stored on the routers. 

• no multicast route prcrtocol messages are communicated or processed. No intra- AS or 
imer-AS route protocols. 
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• Minimum administrate b complexity. No need for complicated kxtcr-AS peering agreements* 
It's just as easy for a network administrator to support multicast as it is to support umcast 
And ft will be just as easy to support multicast across the Internet as it is to support outcast 

• traffic follows the correct paths. Traffic is not concentrated in a small part of the network. 
Minimum network latency. Maximum network efficiency. 

• no need for class D addresses which means 

♦ no need for a server that hands out class D addresses which can be a bottleneck or a point 
of failure 

* no one can join the dass D group and "eavesdrop" on the class D address. The source 
knows who he's sending to. 

• the scheme can be easily adapted to provide a 4 tdiable multicast* 

The advantages of the small group multicast (or SGM) scheme suggest that this scheme can be a 
very useful complement to the existing multicast schemes. Whereas the existing schemes can 
support a limited number of very large multicast groups, the SGM scheme can support a huge 
number (ie virtually an unhmfted number) of small multicast groups and thus can play an 
important role in supporting applications such as conferencing applications on the Internet 

Status 

An initial implementation of small group multicast has been implemented at IBM's T. J. Watson 
Research Center in Hawthorne, New York. The initial implementation includes a simple 
application program that runs on ADC called mchat (for multicast chat), an SGM layer that is 
linked with a multicast application, and a simple SGM router stub that runs on ADC 
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mpTfe possible to improve thirds by caching web content closer to users or usfog an eternal-like 
sandpiper-like "content dfstrfbutlon network", Presumably there are server? (e,g, w3Jbrn.com) thai 
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Snrtion P MufttoSt (9GIVU is a new W*** t0 multicast that we're worfdng in 




SGM complements 

^ST^^S ^ ^ auwwla large number of smalt multicast groups and 
thus can play an important role ,n making multicast practical for now classes cf^^io^ s^n 

t ^?° r ?l V !i 0 ^ conferencift9 and colteboratlve applications, nefcvork-based etf ucffflqn 
multiparty networked games, replication and distribution of Internet contetfetc^ * 
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Rick Boivie 




asked for additional Iftoupftts on the Content Distribution Network Proposal. 




Content Distribution Networfc solution: 

Many of today's ISP's are moving beyond baste I nternet oonnectiyft 
- higher value nnvlffli Iflft f! 1 "" web I 




_ I a Content Distribution service so that 

i irah generate aaaroonai revenue and b) so that it can use its bandwidth more efficiently 
provide better response times etc. 



This project vyBi develop a Content Distribution soii4?on4flHflBHBHfr 

that we win provide win involve content distribution serv^SWIfime^ 

cachli * 




The solution 
lag content distribution / 
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Project Description 

Small Group Multicast (or SGM) Is a new approach to multicast that provides a useful complement to 
today's multicast schemes. Whereas today's multicast schemes are scaleabte in the sense that they cap 
support very la*$e multicast groups, these schemes have problems when a network needs to support a 
very targe number of distinct multicast groups. SGM complements the existing multicast schemes In 
thai tt can support a very large number of small multicast groups end thus can play an important role In 
making multicast practical for new classes of applications such as IP telephony, various conferencing 
and collaborative applications, network-based education, multiparty networked games, replication and 
distribution of Internet- content eta 

We've defined 2 flavors of Small Group Multicast. There is an unrentable variant for applications in which 
there is no provision for retransmitting packets that are lost due to network congestion or because they 
were garbled during transmission, say. This kind or "unreliable" transmission is useful in many 
applications In which the "timeliness* of packet delivery Is more important than getting en "oto m packet 
that was losi re-transmitted. IP telephony and video conferencing are applications in which the • 
timeliness of packet delivery <s important and the retransmission of lost packets is not useful, in other 
applications ft mates sense to retransmit a lost packet even If the retransmitted packet is going to be a 
little "late". For example an application that "poshes* content from a primary server to a set of secondary 
servers would use a reliable multicast that makes use of retransmissions to insure that the content Is 
delivered accuratety, 
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